What's New in v2
Feed Clips v2 moves from v1's RPC-style POST endpoints to a RESTful design:
- Fetches use
GET - Resources carry their IDs in the URL path
- Several v1 actions have been renamed or split into distinct endpoints.
Both versions are currently live and fully documented in the API Reference.
What changed conceptually
- GET for fetches with query params. All read operations (
/v2/clips,/v2/tracks/{id},/v2/collections, etc.) are nowGETrequests with filter/pagination params in the query string instead of a POST body. - Path-param IDs. Resource identifiers move from the request body into the URL path (e.g.,
/v2/clips/{id}/play,/v2/tracks/{id}/clips). previewsplit out fromplay. The v1POST /playendpoint accepted apreview=trueflag. In v2 these are distinct endpoints:POST /v2/clips/{id}/playandPOST /v2/clips/{id}/preview.add: The v1POST /addendpoint is nowPOST /v2/clips/{id}/add. The action name is unchanged but the resource context is clearer.- Bulk and single rights-check endpoints replace
/music-check. v2 offersGET /v2/clips/rights(bulk) andGET /v2/clips/{id}/rights(single) instead of the single v1POST /music-check. - Pagination on list responses. List endpoints (
/v2/clips,/v2/collections, etc.) return paginated results via standard query params. reasonenum on rights responses. When a clip is not playable, v2 rights responses include a machine-readablereasonfield.